一旦你明确基于切面编程是实现当前需求的最佳实现方式时，你将面临如下抉择：使用Spring AOP 或 AspectJ？ ,使用Aspect language (code) 风格还是
@AspectJ 注解风格，亦或是Spring XML 风格？
上述抉择受到一系列因素影响，包括应用需求，开发工具，团队对AOP的熟悉度等。
使用最简单的方式完成工作。
Spring AOP比纯AspectJ更简单，它不需要将AspectJ 编译器/织入器耦合到现有开发和编译过程中。
如果你只需要对Spring beans进行切面编程，Spring AOP是最好的选择。
如果你需要对非Spring容器管理的对象进行切面编程（例如典型的实体类）,你需要使用AspectJ。
如果你需要以join points作为切面而非普通方法（join points举例：域的get或set方法，等等），你需要使用AspectJ。
当使用AspectJ,你需要选择AspectJ language（也称为"code style"）或者 @AspectJ注解风格。
显而易见的是，如果你使用的是Java 5.0版本以下的JDK，你的唯一选择是AspectJ language（"code style"）。
如果切面在你的设计中处于核心的地位，并且你能够使用Eclipse的AspectJ 开发工具（AJDT）插件，AspectJ language是首选，
AspectJ language更简洁，因为设计它的目的就是用来写切面。
如果你没有使用Eclipse，或者只写一小部分切面即切面在你的应用中处于非核心地位，你也许可以考虑使用@AspectJ注解
在你的IDE中依旧使用常规Java编译器，并在编译脚本中加入一个切面编织阶段。
如果你选择使用Spring AOP,你有2个选择 @AspectJ 注解风格或XML风格。
下面有一些取舍的部分需要考虑.
XML风格被现有的Spring用户所熟悉并且能很好的支持POJOs。
当使用AOP作为一个工具用来配置企业级服务时，XML风格是一个好的选择。
（XML风格的一个好处是切点表达式作为你配置的一部分，你可以独立的修改他们）.
使用XML风格可以清晰明确的知晓你系统中配置的切面。
XML风格有2个弊端。
首先，它没有完全封装，即没有将切面定义与切面业务实现封装在一个地方。
DRY原则声明对于系统中任何一个需求的实现应该是：单一、明确、权威的。
当使用XML风格，切面定义与切面业务实现分离了，切面定义在XML中，而切面业务实现在Bean中。
当使用@AspectJ注解风格时，这里只用一个单一模块即切面定义和切面业务实现被封装在一处。
其次,XML风格相比@AspectJ注解风格，对切面的定义有一定的局限性：只支持单一切面，并且不支持两个已命名的切面进行合并。
举例说明 ，在@AspectJ风格，你可以如下方式定义切面：
@Pointcut(execution(* get*()))
public void propertyAccess() {}
@Pointcut(execution(org.xyz.Account+ *(..))
public void operationReturningAnAccount() {}
@Pointcut(propertyAccess() && operationReturningAnAccount())
public void accountPropertyAccess() {}
在XML风格中，你只能定义前2个切面
<aop:pointcut id="propertyAccess"
expression="execution(* get*())"/>
<aop:pointcut id="operationReturningAnAccount"
expression="execution(org.xyz.Account+ *(..))"/>
以XML风格定义的缺点是 你无法以合并两个切面的方式定义 accountPropertyAccess 切面。
@AspectJ 注解风格支持额外的实例化模式，并且更丰富的切面合成.
It has the advantage of keeping the aspect as a modular unit. 它具有将切面作为模块单元的优势.
@AspectJ风格的另外一个优势是，既能够应用于Spring AOP 有能够应用于纯AspectJ。
如果未来你决定使用纯AspectJ的功能来实现额外的需求，你可以非常容易的进行迁移。
权衡利弊后，无论你是将切面编织作为你系统的核心，还是简单的配置企业级服务,Spring团队推荐使用@AspectJ风格来实现基于切面的编程。